Re: Proposal: OID wraparound: summary and proposal
От | Neil Tiffin |
---|---|
Тема | Re: Proposal: OID wraparound: summary and proposal |
Дата | |
Msg-id | p05100300b795a57f6e26@[165.247.90.238] обсуждение исходный текст |
Ответ на | Re: Proposal: OID wraparound: summary and proposal (Hannu Krosing <hannu@tm.ee>) |
Ответы |
Re: Proposal: OID wraparound: summary and proposal
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | pgsql-hackers |
At 10:09 AM +0500 8/7/01, Hannu Krosing wrote: >Neil Tiffin wrote: >> >> I would just like to comment that for our project, GNU Enterprise, we >> use our own 128 bit object ID that is unique (UUID) for every row in >> all tables. >> >> It seems to me, without having looked into it, that having both a >> PostgreSQL UID and our own 128 bit objectid (UUID) is redundant and >> slows the whole process down. But we are storing object data in the >> database and require and absolutely unique objectid. We are planning >> for enterprise usage and expect to need 128 bits to uniquely define >> our objects. > >Is it just an 128-bit int from a sequence or does it have some internal >structure ? > >What kind of enterprise do you expect to have more than >18 446 744 073 709 551 615 of objects that can uniquely be identified >by 64 bits ? Our objectid is a UUID from libuuid (provided by e2fsprogs, requires development files. debian package uuid-dev provides all necessary files.) We use the text representation which IIRC is 33 characters (38 minus the "-") to store it in the database. (And I dont think this is the best way to do it.) As for 64 bits being enough, you may just be right. Our developer that did this part of the code has left (and we are taking the opportunity to examine this). We will eventually compete with SAP, Peoplesoft etc. and consider that SAP has about 20,000 tables to represent an enterprise plus the life of the system at 10 years and you start to knock down the number very fast. I think in the short term we could be happy with a 64 bit id. As we don't even have our first application working (but we are within a couple of months) and it will be years before we have a system that will perform in large scale environments. In either case the perfect solution, for us, would be to be able to configure the PostgreSQL uid as none, 64 bit or 128 bit uid at compile time. A default of 64 bits would be just fine. But we need to have the uid unique for the database or we will still have to create and use our own uid (and that will slow everything down). I have not even considered multiple database servers running different database, which is our design goal. In this case we would like to have a slimmed down (and blazingly fast) PostgreSQL server in which we manage the uid in our middleware. This is because the uid must be unique accross all servers and database vendors. (I don't claim to be a database guru, so if we are all wet here please feel free to help correct our misunderstandings.) -- Neil neilt@gnue.org GNU Enterprise http://www.gnuenterprise.org/ http://www.gnuenterprise.org/~neilt/sc.html
В списке pgsql-hackers по дате отправления: